Post not yet marked as solved
An honest to goodness bug. That's pretty cool. Here's the link to the bug: https://bugs.swift.org/browse/SR-11969. Thanks for taking a look!
Post not yet marked as solved
Removing Cocoapods still crashes. But! Adding `@frozen` to the struct makes it not crash. https://docs.swift.org/swift-book/ReferenceManual/Attributes.html#ID620
Post not yet marked as solved
I submitted a reply yesterday with a link to my repo where I've reproduced this with a small project and framework. That post is still under moderation so I figured I'd post a reply to let you know I've not left you hanging.
Post not yet marked as solved
I have. I've created a repo with both projects here: https://github.com/zach-babb-streem/build-library-for-distribution-bug-reproducer . The build fails on iOS simulators and devices running iOS 12.x, and works on those running iOS 13. I've verified the behavior in my last post with these small projects.
Post not yet marked as solved
I've taken this over from Dave Goldman PDX. This is due to enabling BUILD_LIBRARY_FOR_DISTRIBUTION in a dependent cocoapod that we are developing. Unfortunately I cannot seem to resolve the issue. The behavior is that public structs in the cocoapod are causing this error when declared as class properties. The baffling part is that using that symbol any other way seems to work, i.e. in another class or in a later function like viewDidLoad. Soclass ViewController: UIViewController {
@IBOutlet weak var button: UIButton!
var myStruct: PodStruct?
...
}Doesn't work.But declaring a new class Test does:class Test {
var myStruct: PodStruct?
}
class ViewController: UIViewController {
@IBOutlet weak var button: UIButton!
var test = Test()
...
}And also using the symbol later also works:class ViewController: UIViewController {
@IBOutlet weak var button: UIButton!
override func viewDidLoad() {
super.viewDidLoad()
var myStruct: PodStruct?
}
...
}Changing the struct to a class also works. I thought it might be related to the known issue in Xcode 11.2 release notes about how module and type names can't be the same, but even after changing the type name we still have this issue. Any insight into what may be going on would be greatly appreciated.
